1. Field of the Invention
This invention relates to a method of coordinating the quiescing (i.e., termination or suspension) of the various threads of a multithreaded process.
2. Description of the Related Art
Computer operating systems—the software that interfaces between user applications and the hardware and performs the basic supervisory functions in a computer system—are well known in the art. Many modern operating systems allow for the use of multiple threads within a process, or application. A multithreaded application is defined as a program using more than one thread of control to perform its work. (The terms “process” and “application” are used interchangeably in this specification to refer to one or more threads sharing a common address space.) A. S. Tanenbaum, Modern Operating Systems, (1992), incorporated herein by reference, describes several modern operating systems generally, as well as threads in particular at pp. 507-23.
A particular example of an operating system supporting multithreaded applications is the IBM MVS/ESA operating system with its recently introduced OpenEdition MVS extension. The OpenEdition MVS extension allows applications written to the IEEE POSIX 1003.1, 1003.2 and 1003.4a (draft) standards to run on a hardware-software platform made up of an IBM System/390 computer and the MVS/ESA operating system. (IBM, OpenEdition, MVS/ESA and System/390 are trademarks of IBM Corporation.) Further information on the OpenEdition MVS extension may be found in the following publications, which are incorporated herein by reference:                Ault, “Fork Clone Address Space Implementation on MVS”, IBM Technical Disclosure Bulletin, vol. 35, no. 6, pp. 363-67 (November 1992);        Ault, “Interoperability Between MVS and POSIX Functions”, IBM Technical Disclosure Bulletin, vol. 35, no. 6, pp. 383-88 (November 1992);        Ault et al., “Cross-Address Space Control Function”, IBM Technical Disclosure Bulletin, vol. 36, no. 10, pp. 591-95 (October 1993);        Introducing OpenEdition MVS, IBM Publication No. GC23-3010-00 (1993);        MVS/ESA Support for IEEE POSIX Standards: Technical Presentation Guide, IBM Publication No. GG24-3867-00 (1993).        
As noted above, the OpenEdition MVS extension of the MVS/ESA operating system allows for the use of multiple threads within a process. In MVS terms, a thread can be thought of as a task. Multiple threads thus equate to the use of multiple MVS tasks within an MVS address space.
Although multithreaded applications are advantageous in many situations, lack of adequate task control in a multitasking (i.e., multithreaded) address space causes problems in termination, debugging and dumping. Thus, the POSIX standard calls for the termination of all threads within a process if any one of those threads terminates abnormally. This can be accomplished in MVS by abending the job step task or by using CallRTM to abend the appropriate tasks. Many problems are encountered however, when these types of asynchronous abends are sent to the MVS tasks that were supporting OpenEdition MVS threads.
One problem that occurs is that the run-time library cannot serialize its cleanup of common process resources when the threads of the process are taken down in this abrupt, random manner. Another is that many components do not have sufficient error recovery to handle being abended between any two instructions. In some cases these deficiencies can have catastrophic results, destruction of the file system, to name one. Although the abend error recovery procedure might be improved, it would be preferable to avoid this type of abending altogether.
The desire to suspend the remaining threads of a multithreaded application in a controlled manner may arise in a debugging context. When debugging a multithreaded application, it would be desirable to allow a user debugging such an application to choose which threads run and which threads are suspended for any particular event and to be able to change the run/suspend status dynamically. This suspension process also should be of a sort that neither changes the flow of the application nor allows any thread to hold a critical system-managed resource at the time of suspension.
Another context in which the desire to suspend the remaining threads of a multithreaded application may arise is when obtaining a dump of the process with information captured from all of the threads. The desire here is similar to that in the debugging situation described above. The task requesting the dump should be able to suspend the execution of all the other tasks such that the other tasks do not hold any critical system resources that would prevent the calling task from taking the dump. After the dump is taken, the dumping task must resume execution of the other tasks.
Thus, lack of adequate task control in a multitasking address space causes problems in termination, debugging and dumping. What is desired is a mechanism for terminating or suspending execution of tasks in a multithreaded environment in a predictable and nondestructive fashion.